プロビジョニング＆デプロイ on AWSのキホン #jawsdays – JAWS DAYS 2014 参加レポート Vol.12

#レポート

#AWS

じゅんじゅん

2014.03.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

レポート

くどうです。

さて、Jaws Days 2014に参加したレポートになります。

参加したセッションの情報は以下です。

プロビジョニング＆デプロイ on AWSのキホン

吉羽龍太郎（よしばりゅうたろう）

AWSを利用すると伸縮自在なインフラストラクチャを構築することが可能です。このような環境では頻繁にインスタンスが入れ替えられたり、アプリケーションをデプロイしなおしたりする必要がありますので、自動化が必須です。本セッションではAWS環境におけるプロビジョニングやデプロイの自動化におけるキホンについて解説します。

こんな話しでした

Immutable Infrastructure　はすぐに実現できる？
- できない
基本：自動化する
- ライフサイクルを含めて
基本：ビックバンを避ける
- 小さくリリース
インフラもソフトウェア
- コードでインフラを書く
- 構築に時間がかからない
- コード＝手順書
- 同じコードで同じサーバー
- 再利用
- 使いまわし
基本：連続体としてとらえる
- インフラのプロビジョニング
- AWSでは1時間で1000回のデプロイが行われている
自動化しないリスク
- 作業は繰り返し
- 手順書がメンテされないリスク
- マニュアル作業によって間違うリスク
- 職人芸依存へのリスク
- リリースに失敗するリスク
- 戻れないリスク
- 対象が増えると作業時間と失敗リスクが増加
- コスト流失のリスク
- 結果的に自信が持てない
- プロセスが重くなるリスク
- 時間がないので人海戦術
自動化に向けて
- なぜ？
自動化に投資するか慎重な判断が必要な領域
- 小規模キャンペーン
- 使い捨てアプリ
- 納品して終わり物
基本：自動化の５R
- Rapid
- Reliable
- Repeatable
- Reduce Risk
- Roll ack
プロジェクトの最初から始める
- 顧客や上司の理解を得る
- こっそりは無理
- 説明責任
- 便利ツールとは次元のちがう話し
継続的に改善できる仕掛けを作る
デプロイの自動化
デプロイしやすいアーキテクチャの維持
AWSでのアーキテクティング
- 故障のための設計
- 疎結合なコンポーネント
- 弾力性のある実装
- 前例やでセキュリティ担保
- 並列処理の実装
- 異なるストレージの使い分け
デプロイに自動化に必要な要素
- バージョン管理システム
- 自動化されたテスト
- マイグレーション
- 継続的インテグレート
- デプロイツール
- 静的解析・コードレビュー
バージン管理
- 全ての基本
- チーム全員が使い方を理解するのが当たり前
- しつけの問題
- コードの共同所有
- 環境の再現ができる
- コレができなければ先に進む意味がない
自動化されたテスト
- 速度維持と品質維持
- どこまでテストを用意する
- テストのしやすさ＝デプロイのしやすさ
マイグレーション
- 人が判断しない原則
継続的インテグレーション
- プロジェクトの生命製
アンチパターン
デプロイ自動化
- デプロイプロセスの設計
- 実現方法は変化する
デプロイのパターン
アンチパターン
- 手作業混合
ツールの選択
- Beanstalk＆OpsWorks
ブルーグリーンデプロイ
デプロイ失敗の検知
あとからデプロイ自動化する場合
- プロビジョニング
- プロビジョニング自動化の進め方
- デプロイとプロビジョニングは連続体
AWSのプロダウとの位置づけ
- サービス型
  - Elastic Beanstalk
  - OpsWorks
- 自己管理型
  - CloudFormation
  - EC2
AMI作成の3つの選択肢
- 全部いり
- サードパーティ
- OS
- Packer＋Chef-Soloなんかで→自動化できればCIできる
自動化しやすいものを選択性よ自動化できなければ継続的インテグレーションができる
Sensu
ベストプラクティス
- プロジェクトの最初から始める
アンチパターン：手作業との併用
アンチパターン：テストがない
途中からの環境構築自動化
まとめ
- 自動化には順番がある
- やるならプロジェクトの最初から
- プロセス設計する
- APIを活用
- 継続的インテグレーション重要
- 手作業をまぜない
- 適切なツールを使う